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<§) Objektmodell und Verfahren zum Erfassen von Informationen 

@ Objektmodell zum Erfassen von Informationen, die 
produktinnovationsbezogene Oaten betreffen, mit einer 
Produktideeschnittstelle zum Erfassen einer Idee fur ein 
Produkt in einem Produktideeobjekt und einer Gestal- 
tungsalternativenschnittstellezum Erfassen einer Vielzahl 
von Gestaltungsalternativen fur das Produkt in einer Viel- 
zahl von jeweijigen Gestaltungsalternative-Objekten. 
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Beschreibung 

[0001] Die vorliegende Erfindung betrifft allgemein die 
Inforniationsverwaltung und im besonderen ein System 
bzw. ObjektmodeU und ein Verfahren zum Erfassen und 5 
Speichern von und Zugreifen auf Informationen, die wah- 
rend der Innovation eines Produktes in einer bestandigen 
und werkzeugneutralen Form verwendet werden. 
[0002] Produktentwicklung wird heutzutage von compu- 
terbasierten Anwendungen untersttitzt, u. a. durch Textver- 10 
arbeitungs- und Grafikwerkzeuge, Abwicklungswerkzeuge 
(Temunkoordinierung/Ablaufsteuerung) und Produktdaten- 
verwaltungswerkzeuge. Der typische Produktentwicklungs- 
zyklus beginnt mil einer Idee fur ein Produkt oder einer Ver- 
besserung fur ein Produkt, das ein Bedurfnis in der Industrie 15 
betnfft oder eine Losung fur ein Problem darstellL Ausge- 
hend von der Produktidee konnen unterschiedliche Ent- 
wurfe (Alternativgestaltungen) untersucht werden und 
schlieBlich wird ein Entwurf bzw. eine Gestaltung ausge- 
wahlt, entwickelt/umgesetzt und implementiert. Wahrend 20 
der Anfangsphasen des Produktentwicklungszyklus werden 
Textverarbeitungs-, Grafik- und Ablaufwerkzeuge oft ver- 
wendet, um Informationen wie Marketinganalysen, projek- 
tierte Entwicklungsablaufe und Beschreibungen iind Be- 
griindungen, die bestimmten ausgewahlten Entwurfen zu- 25 
grunde liegen, zu erfassen. Wahrend der Entwurfs- bzw. Ge- 
staltungsphase werden die Gestaltung betreffende Informa- 
tionen, wie die Gestaltungsspezifikauonen und 3-D-Modcll- 
daten, ublicherweise unter Verwendung eines CAD-Werk- 
zeugs erfaBt. Wahrend der Herstellung des Produkts werden 30 
Informationen zur Teileverfolgung Ublicherweise unter Ver- 
wendung eines PDM-Werkzeugs (PDM: Product Data Ma- 
nagement, Produktdatenverwaltung) erfaBt. Zur Veran- 
schaulichung soU davon ausgegangen werden, daB ein Ent- 
wickler/Gestalter eine Idee fur ein neues Produkt hat. Der 35 
Entwickler ist sich dabei mehrerer Anforderungen bewuBt, 
die das Produkt erfullen muB und hat einige Losungsideen 
Der Entwickler muB mehrere unterschiedliche Werkzeuge 
benutzen, um Darstellungen unterschiedlicher Teile der Lo- 
sung zu crzcugcn. Bcispiclswcisc bcnutzt der Entwickler 40 
Microsoft Excel zum Erzeugen einer Kostenanalyse Corel 
zur graphischen DarsteUung, SolidDesigner fur ein erstes 
Raumbudget und Work-Manager von CoCreate zur Erzeu- 
gung cincr crstcn Funktionsorganisation. 
[0003] Wahrend es klar ist, daB unterschiedliche compu- 45 
terbasierte Werkzeuge die Erfassung von Informationen und 
das Verfolgen des Forlschritts eines Produkles unlerstuUen 
weist der Stand der Technik einige Nachteile auf. Erstens 
existiert derzeit kein Werkzeug, das konkret zur Erfassung 
und Verfolgung von Keen und Entscheidungen zu diesen so 
Ideen wahrend der Anfangsphasen der ProduklenlwicUung 
dient. DieUntersuchung von Ideen ist haufig eine Situation 
in der viel Empirie bzw. Regula falsi (trial and error) betrie- 
ben wird. Um eine derartige Untersuchung erfolgreich ver- 
folgen zu konnen, ist es notwendig, viele nur teilweise voll- 55 
standigen Informationsstrukturen, die Entscheidungen, ei- 
nen Untersuchungsweg weiterzuverfolgen oder aufzugeben 
und die Erklarungen/Begriindungen hinter diesen Entschei- 
dungen zu erfassen. Es ist auch niitzlich, die Absicht bzw. 
den Zweck einer bestimmten LosungsalternaUve zu erfas- 60 
sen. Im Stand der Technik existiert kein einzelnes Werkzeug 
zum Erfassen und Verfolgen derartiger wichtiger Informa- 
tionen einschlieBlich der Beweggriinde und Ziele eines Ent- 
wurfs, Fragen, Ideen und Antworten, die wahrend der Un- 
tersuchung des Entwurfs gestellt werden, und der gleichen 65 
Informationen bezuglich ebenfalls untersuchter Gestal- 
tungsalternativen. Selbst wenn einigeder Informationen un- 
ter Verwendung eines oder mehrerer unterschiedlicher 



Werkzeuge erfaBt wird, weil die Informationen nicht inte- 
gnert oder einfach zuganglich sind, auBer das bestimmte 
Werkzeug, das zur Erfassung der Informationen benutzt 
wurde, wird verwendet, werden des weiteren viele der an- 
fanglichen Gestaltungsabsichten und Erklarungen/Beweg- 
griinde von Gestaltungsentscheidungen sowie die unter- 
suchten Gestaltungsaltemativen ublicherweise nicht effek- 
Uv erfaBt oder gehen mit Fortschreiten des Entwickluneszv- 
klus des Produkts verloren. 

[0004] Zusatzlich werden im Stand der Technik alle ent- 
wurfsbezogenen Informationen, die unter Verwendung eines 
bestimmten computerbasierten Werkzeugs erfaBt werden, 
ublicherweise nur iiber das zur Erzeugung der Daten ver- 
wendete Werkzeug gespeichert, verwaltet und abgerufen. Es 
gibt mehrere Grunde, warum die Moglichkeit, auf Daten 
die von einem Werkzeug erzeugt wurden, unter Verwendung 
anderer Werkzeuge zugreifen zu konnen, vorteilhaft ware. 
Insbesondere konnen die Informationen, die unter Verwen- 
dung eines Werkzeugs erfaBt wurden, fur unterschiedliche 
Menschen von unterschiedlichen Einheiten, die unterschied- 
liche Aufgaben wahrnehmen, interessant sein. So konnen 
beispielsweise Informationen, die wahrend des Entwurfs 
bzw. der Gestaltung eines Produkts erfaBt wurden, nicht nur 
fur die Gestaltungsingenieure, sondern auch fur die Ilerstel- 
lungs- und TesUngenieure, Fuhrungskrafte im Produktent- 
wicklungsprozeB, Wartungstechniker, Marketing- und Ver- 
kaufspersonal, Disponenten, Personal in der Auftragsverar- 
beitung, Website-Entwickler und -verwalter, Kunden, Zulie- 
ferer usw. nutzlich sein. 

[0005] Es existiert demnach ein Bedurfnis, Informationen 
zur Produktentwicklung, nachfolgend als "Innovationsinfor- 
mationen" bezeichnet, einschlieBlich Produktideen, Gestal- 
tungsaltemativen, Fragen und Antworten, die wahrend des 
Innovauonsprozesses untersucht wurden, Entwurfsentschei- 
dungen usw. zu erfassen, zu speichern und abzurufen. Es be- 
steht auch ein Bedurfnis, die Innovationsinformation in ei- 
ner werkzeugneutralen Form zu erfassen, die jedem Werk- 
zeug einen Zugriff auf die (und ggf. auch eine Modification 
der) Innovationsinformauonen gestattet. Ein derartiges 
Werkzeug wiirdc die Verfolgung der graducUcn Entwick- 
lung vom Entwurf und Entscheidungen iiber den Entwurf 
uber die Evolution des Produkts gestatten und dabei die 
funktionalen entwurfsbezogenen Aspekte eines Produkts 
(ansiatt wic im Stand der Technik lcdiglich die rcalisicrtcn 
Konfigurationen des endgultigen Produkts) erfassen und ein 
Verfolgen und Nachvollziehen deren Entwicklung gestatten. 
[0006] Demgegenuber wird erfindungsgeiiiiu3 ein Objekt- 
modeU zum Erfassen von Informationen mit den Merkma- 
len des Anspruchs 1, ein Verfahren zum Erfassen von Infor- 
mationen mit den Merkmalen des Anspruchs 10 sowie ein 
Compulerprogramm mil den Merkmalen des Anspruchs 18 
vorgeschlagen. 

[0007] Die vorliegende Erfindung besteht demnach aus ei- 
nem System und einem Verfahren zum Erfassen und Spei- 
chern von und Zugreifen auf Innovationsinformationsdaten 
m einer bestandigen und werkzeugneutralen Form, die einen 
Datenzugnff durch jedes Werkzeug uber eine offentlich de- 
fimerte Schnittstelle gestattet. Die Erfindung erfaBt den kla- 
ren inkrementalen Aufbau von Innovationsinformationen 
einschlieBlich Produklideen, Gestaltungs- bzw. Entwurfsal- 
ternativen, Fragen und Antworten, die wahrend des Innova- 
tionsprozesses untersucht wurden, Entwurfsentscheidungen 
usw. Die Innovationsinformationen sind in einer Form dar- 
gestellt, die unter Verwendung unterschiedlicher computer- 
basierter Anwendungen abgefragt und auf verschiedene 
Weisen wiedergegeben werden kann. 
[0008] Die Erfindung erfaBt den evolutionaren Aufbau 
von Informationen, die die Ausgangsidee und die Untersu- 
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chung eines Produkts iiber die Zeit beireffen. Wahrend der 
Untersuchung eines Produkts werden viele Altemativen 
vorgeschlagen und erforscht. Es werden Entscheidungen ge- 
fallt, die Moglichkeiten ausschlieBen. Mit Fortschreiten der 
Gestaltung und der Ehtwicklung andern sich die gestellten 
Fragen und zugehorigen Antworten unter dem EinfluB von 
umfassenden Entscheidungen und dem Aufkommen von 
mehr ins Detail gehenden Fragestellungen. Teile der Pro- 
duktdefinition bewegen sich mit unterschiedlicher Ge- 
schwindigkeit von der Idee zur vollstandigen Definition. 
Das Innovationsinformalionen-Objektmodell der Erfindung 
unterstiitzt das Verfolgen bzw. Nachvollziehen der funktio- 
nalen gestaltungsorientierten Aspekte des Produkts. Das ge- 
staltungsorientierte Verfolgen stellt somit ein Zeitspektrum 
vom Untersuchen von Produktideen bis zur vollstandigen 
und fur die Produktion freigegebenen Produktdefinition be- 
reit. Die Informationen entwickeln und gestalten sich gradu- 
ell und werden mit fortschreitendem GestaltungsprozeB im- 
mer detaillierter. Die Moglichkeit fur Innovation ist gege- 
ben, solange Fragen offen sind, die kreative Antworten er- 
fordern. Die Auswirkung von Innovation bewegt sich von 
global zu lokal, wenn Entscheidungen gefallt und Detailfra- 
gen angegangen werden. 

[0009] Die vorliegende Erfindung umfafit vorzugsweise 
ein Objektmodell zur Verwaltung von Innovationsinforma- 
tionen (nachfolgend kurz als IIM-Objektmodell hezeichnet), 
das unterschiedliche Objektmodelle erfaCt und speichert, 
die Informationsartikel und deren zugehorige Beziehungen 
in einer Objektmodelldatenbank umfassen. Jedes Objektmo- 
dell beinhaltet Informationen und Beziehungen, die iiher 
eine offentlich definierte Schnittstelle zuganglich sind. In ei- 
ner Ausfuhrungsform werden beim Speichern eines Objekt- 
modells in die Objektmodelldatenbank unterschiedliche TV- 
pen von Informationsartikeln bzw. Einzelinformationen, die 
in dem Objektmodell zusammen mit ihren Beziehungen zu 
anderen Informationsartikeln bzw. Einzelinformationen ent- 
halten sind, in unterschiedlichen relationalen Datenbankda- 
teien, die mit den Informationsartikeln verkniipft sind, ge- 
speichert. Anwendungen, die auf die Objektmodelldaten- 
bank zugrcifcn, vcrwcndcn lcdiglich die definierte Objckt- 
modellschnittstelle, was zu einer automatischen Trennung 
und Speicherung von Datentypobjekten in einer bestandigen 
werkzeugneutralen Form fuhrt. 

[0010] Die Erfindung crlcichtcrt den Zugriff auf Informa- 
tionen mittels jeglicher Anwendung iiber die definierten Ob- 
jektmodellschnittstellen, unabhangig davon, durch welche 
Anwendung die Objekte erzeugt wurden. Dadurch entslehl 
kein "Besitz" an den Daten durch eine Anwendung oder 
durch das Werkzeug, das die Daten erzeugt hat. 
[0011] Die Erfindung erleichtert auch anspruchsvolle Su- 
chen in den Objeklmodellen, um interessierende Infonnalio- 
nen aus der Gesamtheit der gespeicherten Informationen 
herauszuziehen. Die Erfindung ist in vielerlei Hinsicht vor- 
teilhaft, einschlieBlich der Moglichkeit fur eine Mehrzahl 
von Menschen mit unterschiedlichen Aufgaben und Posten, 
auf die Informationen zuzugreifen und diejenigen Informa- 
tionen herauszuziehen, die ihrer Aufgabe bzw. ihrer Position 
entsprechen. 

[0012] Weitere Vorteile und Ausgestaltungen der Erfin- 
dung ergeben sich aus der Beschreibung und der beiliegen- 
den Zeichnung. 

[0013] Es versteht sich, daB die vorstehend genannten und 
die nachstehend noch zu erlautemden Merkmale nicht nur in 
der jeweils angegebenen Kombination, sondern auch in an- 
deren Kombinationen oder in AUeinstellung verwendbar 
sind, ohne den Rahmen der vorliegenden Erfindung zu ver- 
lassen. 

[0014] Die Erfindung ist anhand von Ausfuhrungsbeispie- 



len in der Zeichnung schematisch dargestellt und wird im 
folgenden unter Bezugnahme auf die Zeichnung ausfuhrlich 
beschrieben. 

[0015] Fig. 1 zeigt ein konzeptionelles Objektmodelldia- 
5 gramm, das die Trennung von Informationsartikeln und ih- 
rer zugeordneten Beziehungen zu anderen Informationsarti- 
keln darstellt. 

[0016] Fig. 2 zeigt ein Blockdiagramm eines erfindungs- 
gemaBen ObjektmodeUs zur Verwaltung von Innovationsin- 

10 formationen. 

[0017] Fig. 3 zeigt ein UML-Schnittstellendiagramm 
(UML: Unified Modelling Language), das eine bevorzugte 
Ausfuhrungsform der Schnittstelle fur das Objektmodell zur 
Verwaltung von Innovationsinformationen (IJM-Objektmo- 

15 dell) fur das in Fig. 2 gezeigte nM-Objektmodell darstellt. 
[0018] Fig. 4 zeigt ein Blockdiagramm der von dem IIM- 
Objektmodell der Fig. 2 unter Verwendung der in Fig. 3 de- 
finierten Schnitlstellen erzeugten und unterhaltenen bestan- 
digen Speichereinheiten bzw. -entitaten. 

20 [0019] Fig. 5 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe Pro- 
duktidee-Tabelle umgesetzt wird. 

[0020] Fig. 6 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe Pro- 

25 duktanforderungen-Tabelle umgesetzt wird. 

10021 ] Fig. 7 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe Ge- 
staltungsaltemativen-Tabelle umgesetzt wird. 
[0022] Fig. 8 zeigt ein Anschauungsbeispiel einer relatio- 

30 nalen Datenbankdatei, mit der eine erfindungsgemaBe Pro- 
duktfunktion-Tabelle umgesetzt wird. 
[0023] Fig. 9 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe An- 
forderungserfiillung-Tabelle umgesetzt wird. 

35 [0024] Fig. 10 zeigt einen Produkiidee-Dialog fiif eine er- 
findungsgemaB umgesetzte grafische Benutzerschnittstelle. 
[0025] Fig. 11 zeigt einen Produktanforderung-Dialog fiir 
eine ertindungsgemaB umgesetzte grafische Benutzer- 
schnittstelle. 

40 [0026] Fig. 12 zeigt einen Produktfunktion-Dialog fur 
eine erfindungsgemSB umgesetzte grafische Benutzer- 
schnittstelle. 

[0027] Fig. 13 zeigt einen Gestaltungsallemativen-Dialog 
fur cine crfindungsgcmaB umgesetzte grafische Bcnutzcr- 
45 schnittstelle. ■■ 

[0028] Fig. 1 zeigt ein konzeptionelles Blockdiagramm, 
das die Trennung von Infonnationsartikeln bzw. Informali- 
onsgegenstanden bzw. Einzelinformationen und deren zuge- 
horigen Beziehungen zu anderen Informationsartikeln so- 
so wie die Zugreifbarkeit auf die Informationen mittels unter- 
schiedlicher Werkzeuge darstellt. Insbesondere sind eine 
Ansammlung von Objektmodellen 10a, 10b, 10c, 10d, lOe 
und lOf, die Informationen und von einer Anzahl unter- 
schiedlicher Werkzeuge 20a, 20b, 20c, . . ., 20n wahrend der 
55 Entwicklung eines Produktes erzeugte Objektbeziehungen 
beschreiben, in werkzeugneutraler Form in einem bestandi- 
gen Speicher 30 gespeichert. Dabei ist es wichtig, daB die 
Objektmodelle 10a, 10b, 10c, lOd, lOe und lOf nicht einem 
bestimmien Werkzeug "gehoren", insbesondere nicht den 
60 Werkzeugen 20a, 20b, 20c, 20n, von denen sie erzeugt wur- 
den. Jedes Objektmodell 10a, 10b, 10c, lOd, lOe und lOf 
enthalt Objekte, die hochst abhangige Objektbeziehungen 
aufweisen. 

[0029] Die Objektmodelle 10a, 10b, 10c, lOd, lOe und lOf 
65 verfugen jeweils iiber eine definierte offentliche Schnitt- 
stelle, die es einem jeden die Schnittstellendefinition verste- 
henden Werkzeug 20a, 20b, 20c, . . ., 20n gestattet, zulassige 
Daten in den entsprechenden Satz von Objekten zu schrei- 
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ben und herauszulesen. Auch wenn die Situation eintreten 
kann, daB lediglich ein Anwendungswerkzeug ein einzelnes 
Attribut vollstandig versteht (wie ein CAD-Werkzeug, das 
eine 3D-Geometrie und -topologie versteht), gestattet es die 
offentliche SchnittsteUendefinition im Grunde genommen 5 
jedem Werkzeug, auf Teile des Objekts, das es versteht, ein- 
schlieBlich dessen Beziehungen zu anderen Objekten, zuzu- 
greifen. Beispielsweise erzeugt das CAD-Werkzeug (CAD 
TOOL) 20a (bspw. SolidDesigner von CoCreate) Daten, die 
teilweise in dem Objektmodell "CAD-Modell" (CAD MO- 10 
DEL) 10a und teilweise in dem Objektmodell "Produkt- 
struktur" (PRODUCT STRUCTURE) 10b gespeichert wer- 
den. Es ist wichtig festzuhalten, dafi das CAD- Werkzeug 
20a seme interne Datenstruktur oder seine Benutzerschnitt- 
stelle nicht andern muB. Vielmehr muB das CAD-Werkzeug 15 
20a lediglich die Fahigkeit besitzen, nur diejenigen Objekte 
und Strukturen zu verstehen, die es schreibt und liest, was 
durch Verwenden einer Erweiterung erreicht werden kann, 
die eine Import/Exportfahigkeit gestattet; derartige Techni- 
ken sind im Stand der Technik gut bekannt. In dem vorlie- 20 
genden Beispiel greift ein PDM- Werkzeug (PDM TOOL) 
20b (PDM: Product Data Management; bspw. WorkMana- 
ger von CoCreate) auf das Modell "Produktstruktur" 10b 
und das Modell "Gestalcungsaltemative" (DESIGN AL- 
TERNATIVE) 10c zu. Entsprechend muB das PDM-Werk- 25 
zeug 20b die Fahigkeit besitzen, an dem Modell "Produkt- 
struktur" 10b von dem CAD-Werkzeug 20a vorgenomme- 
nen Anderungen handhaben zu konnen, und entsprechend 
muB das CAD-Werkzeug 20a die Fahigkeit besitzen, von 
dem PDM-Werkzeug 20b an dem Modell "Produktstruktur" 30 
10b vorgenommenen Anderungen handhaben zu konnen. 
Das gemeinsame Objektmodell (d. h. das Modell "Produkt- 
struktur" 10b), das beide verstehen, unterstutzt und verbes- 
sert dabei die Kollaboration zwischen dem CAD- Werkzeug 
20a und dem PDM-Werkzeug 20b. 35 
[0030] Es ist auch wichtig festzuhalten, daB anderen 
Werkzeuge (bspw. 20n) auch jederzeit auf die Objektmo- 
delle 10a, 10b, 10c, 10d, lOe und lOf zugreifen konnen und 
die Anzahl von Objektmodellen 10a, 10b, 10c, lOd, lOe und 
lOf jederzeit crweitert werden kann. So crweitert und cnt- 40 
wickelt sich die Sammlung von Informationen und Bezie- 
hungen mit anderen Objekten entsprechend wahrend des 
Fortgangs des Produktzyklus, wobei die Emwicklungs- und 
Gcstaltungsaspcktc des Produkts fcstgchaltcn werden. Zu- 
dem gestattet die werkzeugneutrale bestandige Form der 45 
Objektmodelle sowohl synchrone als auch asynchrone Kol- 
laborauon bei der Produklentwicklung, indem vielen unter- 
schiedlichen Benutzern (bspw. Ingenieure, Entscheidungs- 
ebene, Verwaltungspersonal und sogar Kunden) mitentspre- 
chender Berechtigung zum Zugriff auf die in den Objektmo- so 
dellen enlhallenen Daten, die den derzeitigen Stand des Pro- 
dukts darstellen, gestattet ist. 

[0031] Unter den Objektmodellen in der Objektmodellda- 
tenbank 30 befindet sich ein Objektmodell "Verwaltung von 
Innovationsinformationen" (INNOVATION INFORMA- 55 
TION MANAGEMENT) lOe (kurz: HM-Objektmodell), 
das all diejenigen Innovationsinformationen einschlieBt 
bzw. zusammenfaBt, die mit der Entwicklung und Gestal- 
tung ernes Produkts, einschlieBlich Produktideen, Gestal- 
tungsaltemativen, Fragen und Antworten, die wahrend des 60 
Innovationsprozesses untersucht wurden, Gestaltungsent- 
scheidungen usw., verbunden sind sowie ihre Beziehungen 
zu anderen Objekten in dem IIM-Objektmodell lOe und zu 
Objekten in anderen Objektmodellen 10a, 10b 10c 10c 
lOd und lOf. ' ' '55 

[0032] Objekte in dem HM-ObjektmodeU lOe konnen au- 
tomatisch von einem oder mehreren der Werkzeuge 20a, 
20b, 20c, 20n erzeugt werden, oder sie konnen konkret 



von Nutzern uber spezifische HM-Dialoge (IIM: Innovati- 
onsinformationen-Management/Innovation Information 
Management) erzeugt werden, auf den uber die Benutzer- 
schnittstelle der Werkzeuge zugegriffen wird. Zusatzlich 
kann ein HM-Werkzeug (TOOL) 20c zur konkreten Eingabe 
von Innovationsinformationsdaten entwickelt werden. Wie 
jedoch schon vorstehend angemerkt wurde, "gehoren" kei- 
nem Werkzeug die Daten in dem EM-ObjektmodeU lOe und 
jedes Werkzeug kann auf die Daten in dem IIM-Objektmo- 
dell lOe uber offentlich definierte Schnittstellen, die mit 
dem HM-ObjektmodeU lOe in Verbindung stehen, zugrei- 
fen. Diese offentlich definierten Schnittstellen werden nach- 
folgend noch ausfiihrlich erlautert. 

[0033] Fig. 2 zeigt ein Blockdiagramm, das eine bevor- 
zugte Ausfuhrungsform 100 des IIM-Objektmodells der 
Fig. 1 darsteUt, durch das ein Objektmodell zum Erfassen 
und Speichern der einzelnen Informationen und deren 
Struktur, wie sie wahrend der Untersuchungsphase der Ent- 
wicklung und Gestaltung eines Produkts in einer werkzeug- 
neutralen bestandigen Form entwickelt wurden, bereitsteUt. 
[0034] Wie in Fig. 2 dargestellt umfassen die hauptsachli- 
chen Informationsgegenstande in dem IIM-Objektmodell 
100 die folgenden Objekte: Produktidee (PRODUCT IDEA) 
110, Produktanforderung (PRODUCT REQUIREMENT) 
120, Gestaltungsalternative (DESIGN ALTERNATIVE) 
130, Gestaltungsdarstellung (DESIGN REPRESENTA- 
TION) 140, Produktfunktion (PRODUCT FUNCTION) 
150, Durchfiihrungsbeschrankung (REGULATORY CON- 
STRAINT) 160, Gestaltungsabsicht (DESIGN INTENT) 
170, Gestaltungsmerkmal bzw. Gestaltungsbedeutung bzw 
Gestaltungsanmerkung (DESIGN NOTE) 180, Gestaltungs- 
problem (DESIGN ISSUE) 190 und Gestaltungsbeschran- 
kung (DESIGN CONSTRAINT) 195. 
[0035] Ein Informationsgegenstand (oder Informalions- 
objekt) "Produktidee" 110 schlieSt eine Idee betreffend ein 
Produkt ein. Eine Produktidee kann eine Idee fur ein neues 
Produkt, eine Steigerung oder Verbesserung eines bestehen- 
den Produkts oder die Losung eines bekannten Problems 
(wie eine technische Anderung) fur ein bestehendes Produkt 
scin. 

[0036] Ein Objekt "Produktanforderung" 120 beinhaltet 
eine Anforderung, die das Produkt erfullen muB, soil oder 
kann. Fur ein gegebenes Produkt gibt es iiblicherweise viele 
Anfordcrungcn von viclcn vcrschicdcncn Qucllcn (bspw. 
Marketing, Kunden, Entwicklung, Herstellung). 
[0037] Ein Objekt "Gestaltungsalternative" 130 faBt In- 
formationen zusanunen, die eine mogliche Losung Oder Ge- 
staltung fur eine Idee darstellen, die in einem Objekt "Pro- 
duktidee" 110 zusammengefaBt ist. Ein Objekt "Gestal- 
tungsdarstellung" 140 beinhaltet eine Mbglichkeit, die in ei- 
nem Objekt "Gesudlungsalternative" 130 dargesteUle vorge- 
schlagene Losung oder Gestaltung umsetzen bzw. herstel- 
len. 

[0038] Ein Objekt "Produktfunktion" 150 beinhaltet eine 
Funktion zum Losen einer Produktanforderung. 
[0039] Ein Objekt "Durchfiihrungsbeschrankung" 160 be- 
inhaltet eine Beschrankung, die dem Produkt auferlegt ist 
und sich auBerhalb der Kontrolle der Entwickler/Gestalter 
befindet. Als Beispiel seien hier gesetzlich festgelegte Kom- 
munikationsfrequenzen im Funkbereich genannt 
[0040] Ein Objekt "Gestaltungsabsicht" 170 beinhaltet 
eine konkrete Absicht oder Zielsetzung der Gestaltung. 
[0041] Ein Objekt "Gestaltungsmerkmal" 180 beinhaltet 
ein die Gestaltung betreffendes Merkmal. 
[0042] Ein Objekt "Gestaltungsproblem" 190 ist mit einer 
Gestaltungsdarstellung verbunden. Das in einem Gestal- 
tungsproblem-Objekt enthaltene bzw. zusammengefaBte 
Problem betrifft Bedenken oder eine offene Frage, die nach 
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Belrachten der Darstellung der Gestaltungsaltemative auf- 
gekommen sind.- 

[0043] Ein Objekt "Gestaltungsbeschrankung" 195 faBt 
eine Beschrankung zusaimnen, die der Gestaltungsaltema- 
tive auferlegt ist und iiber die Kontrolle besteht. 
[0044] Innerhalb des HM-Objektmodells 100 existieren 
Beziehungen zwischen den Datenobjekten, wie dies durch 
die Verbindungslinien zwischen den Objekten dargestellt 
ist. Z. B. kann jede Produktidee 110 mil verschiedene Pro- 
duktanforderungen 120 (wie sie von den Entwicklern und 
anderen die Gestaltung beeinflussenden Personen definiert 
werden) verbunden sein, die wiederum keine oder mehrere 
zugeordnete Produktfunktionsobjekte 150 aufweisen kon- 
nen, die vollstandig oder teilweise die in ihrem zugeordne- 
ten Produktanforderungsobjekt 120 niedergelegten bzw. zu- 
sammengefaCten Anforderungen erfullen. Jede Produktidee 
110 kann auch mit einigen Durchfiihrungsbeschrankungen 
160 (wie sie bspw. durch die Industrie oder den Gesetzgeber 
definiert sein konnen) verbunden sein, die wiederum durch 
eine Produktanforderung 120 wie vorstehend beschrieben 
dargestellt sein konnen. Jede Produktidee 110 kann auch mit 
mehreren Gestaltungsalternativobjekten 130 verbunden 
sein, die wiederum mil Gestaltungsabsichtsobjekten 170 
und zugeordneten Produktfunktionsobjekten 150 verbunden 
sein konnen. AuBerdem kann jede Gestaltungsaltemative 
zugeordnete Gestaltungsbeschrankungen 195 und/oder zu- 
geordnete Gestaltungsdarstellungen 140 aufweisen. Jede 
Gestaltungsdarstellung 140 kann zugeordnete Gestaltungs- 
bemerkungen 180 und/oder Gestaltungsprobleme 190 auf- 
weisen. 

[0045] Fig. 3 zeigt ein UML-Schnittstellendiagramm, das 
eine bevorzugte Ausfiihrungsform der nM-Objektmodell- 
schnittstelle fiir das nM-Objektmodell 100 der Fig. 2 dar- 
stellt. Wie in Fig. 3 dargestellt umfassen die fur das HM-Ob- 
jektmodell 200 der Fig. 2 definierten offentlichen Schnitt- 
stellen folgendes: Produktidee (Productldea) 210, Produk- 
tanforderung (ProductRequirement) 220, Gestaltungsalter- 
native (DesignAltemative) 230, Gestaltungsdarstellung 
(DesignRepresentation) 240, Produktfunktion (Product- 
Function) 250, Durchfuhrungsbcschrankung (Regulatory- 
constraint) 260, Gestaltungsabsicht (Designlntent) 270, Ge- 
staltungsbemerkung (DesignNote) 280, Gestaltungsproblem 
(Designlssue) 290, Gestaltungsbeschrankung (DesignCon- 
straint) 295 und Produktspczifikation (Products pecification) 
225. Die Attribute fiir jede Schnittstelle sind wie in Fig. 3 
dargestellt. In der DM-Schnittstellendefinition werden In- 
formalionen iiber jede Produktidee in einem Objekt "Pro- 
duktidee" 110 (Fig. 2) zusammengefaBt, auf das von der 
Schnittstelle Productldea 210 zugegriffen wird. In dieser 
Ausgestaltung hat die Schnittstelle Productldea 210 keine 
oder mehrere Schnittslellen RegulatoryConstrainl 260, von 
denen jede mit keiner oder mehreren Schnittstellen Produc- 
tRequirement 220 verbunden sein kann. Die Schnittstelle 
Productldea 210 kann auch eine Zuordnung zu keiner oder 
mehreren Schnittstellen ProductRequirement 220 aufwei- 
sen, die aus verschiedenen Quellen stammen konnen und 
eine angehangte Beziehiing, die iiber die Schnittstelle Re- 
quirementRelationship 222 definiert ist, aufweisen konnen. 
Eine Schnittstelle ProductSpecification 225 ist eine Erweite- 
rung der Schnittstelle ProductRequirement 220 und wird 
dazu verwendet, Spezifikationen fiir die Anforderungen ge- 
nauer zu definieren. Jede Schnittstelle ProductRequirement 
220 kann auch keiner oder mehreren Schnittstellen Product- 
Function 250 zugeordnet sein, die eine Losung zum teilwei- 
sen oder vollstandigen Erfullen einer Produktanforderung 
bereitstellen. Die Schnittstelle ProductFunction 250 ist in 
der standardisierten Schnittstelle PDMConfigurationMana- 
gement der "Object Management Group (OMG) PDM En- 



ablers" definiert, die aus dem Stand der Technik bekannt und 
in "PDM Enablers: Joint Proposal to the OMG in Response 
to OMG Manufacturing Domain Task Force RFP 1", Paper 
mfg/98-02-02 of der Object Management Group (OMG), 
5 ausfuhrlich beschrieben ist. Die Schnittstelle PDMConfigu- 
rationManagement erweitert den Produktstruktur-Enabler 
zur Unterstutzung von Untemehmen, in denen ein Produkt 
zum Verkauf in vielen unterschiedlichen Komponentenkon- 
figurationen angeboten werden kann. Das Konfigurationen- 

10 verwaltungsmodul erlaubt eine Spezifikation von Produkt- 
klassen und unlerscheidenden Produktkonfigurationen. Ent- 
sprechend ist das UM-Objektmodell der Erfindung kompati- 
bel mit den standardisierten PDM-Enabler-Schnittstellen. 
[0046] Wie ebenfalls dargestellt kann die Schnittstelle 

is Productldea 210 keiner oder mehreren Schnittstellen Desi- 
gnAltemative 230 zugeordnet sein ; die einen Zugriff auf 
keine oder mehrere Objekte "Gestaltungsaltemative" 130, 
die einem bestimmten Objekt "Produktidee" 110 zugeordnet 
sind, gestatten. Jede Schnittstelle DesignAltemative 230 hat 

20 keine oder mehrere Schnittstellen DesignConstraint 295 und 
keine oder mehrere Schnittstellen DesignRepresentation 
240, die jeweils Zugriff auf ein verbundenes Objekt "Gestal- 
tungseinschrankung" 195 und/oder ein zugehoriges Objekt 
"Gestaltungsdarstellung" 140 gestatten. Jede Schnittstelle 

25 DesignRepresentation 240 ist keiner oder mehreren Schnitt- 
stellen DesignNote 280 zugeordnet, die Zugriff auf ein Ob- 
jekt "Gestaltungsbemerkung" 180 gestatten, und mit keiner 
oder mehreren Schnittstellen Designlssue 290, die Zugriff 
auf ein Objekt "Gestaltungsproblem" 190 gestatten. . 

30 [0047] Eine Schnittstelle RequirementFulfillment 255 ge- 
stattet, auf den Grad der Erfullung der Produktanforderun- 
gen, die die Produktfunktion erfullt, zuzugreifen. Dies ge- 
stattet einem Benutzer, das ITM-Objektmodell spater im 
Hinblick auf diejenigen Gestaltungsaltemativen, die be- 

35 stimmte ggf. priorilatsgewichtete Anforderungen erfullen, 
zu untersuchen, um zu ermitteln, welche Gestaltungsaltema- 
tive einer Erfullung der Anforderungen mit den hochsten 
Prioritaten am nachsten kommt. 

[0048] Diese Fahigkeit, das System abzufragen, inderri 
40 wichtigc Fragcn gcstcllt werden, und cine automatischc 
Antwort von dem UM-Objektmodell zu erhalten, ist ein au- 
Berst wichtiger Aspekt, der durch die Erfindung bereitge- 
stellt wird. 

[0049] Ein Satz von Entschcidungsschnittstcllcn gestatten 

45 einem Benutzer, unterschiedliche Entscheidungen, die wah- 
rend der Untersuchungsphase des Produkts getroffen wur- 
den, zu erfassen und aufzufinden. Bspw. gestatlet eine 
Schnittstelle ProductRequirementDecision 215 das Auffin- 
den von Fragen, Antworten und daraus resultierenden Ent- 

50 scheidungen, die mit Produktanforderungen verbunden 
sind. Eine Schnittstelle ProductFunclionDecision 235 ge- 
stattet das Auffinden von Fragen, Antworten und daraus re- 
sultierenden Entscheidungen, die mit der Verwendung von 
vorgeschlagenen Produktfunktionslosungen in einer be- 

55 stimmten Gestaltungsaltemative verbunden sind. Eine 
Schnittstelle DesignAlternativeDecision 275 gestattet das 
Auffinden von Fragen, Antworten und daraus resultierenden 
Entscheidungen, die mit der Auswahl von Gestaltungsalter- 
nativen verbunden sind. Eine Schnittstelle DesignRepresen- 

60 tationDecision 245 gestattet das Auffinden von Fragen, Ant- 
worten und daraus resultierenden Entscheidungen, die mit 
der Auswahl in der Implementierung einer bestimmten Ge- 
staltungsaltemative verbunden sind. 

[0050] Die in dem UML-Diagramm der Fig. 3 definierten 
65 Schnittstellen sind vorzugsweise in einer objektorientierten 
Sprache wie C++ oder Java2 implementiert. Die tatsachli- 
che Klassenimplementierung kann von System zu System 
variieren, da es haufig sinnvoll sein wird, einige der Schnitt- 
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stellen aus Griinden einer effizienten Implementierung und/ 
Oder Leistung (Performance) in einer einzelnen Klasse zu- 
sammenzufassen. 

[0051] Fig. 4 zeigt ein Blockdiagramm, das eine Ausfuh- 
rungsform der bestandigen Speicherenritaten darsteUt, die 
von dem HM-Objektmodell 100 der Fig. 2 unter Verwen- 
dung der in Fig. 3 definierten SchnittsteUen erzeugt und un- 
terhalten werden. In dieser Ausfuhrungsform ist mit jeder 
Schnittstelle eine bestandige Speicherdatei, vorzugsweise in 
Form einer relationalen Datenbank, verbunden. Die von der 
jeweihgen SchnittsteUe eingeschlossenen Daten sind in der 
jeweiligen zugehorigen relationalen Datenbankdatei gespei- 
chert. Entsprechend gibt es eine separate relationale Daten- 
bankdatei fiir jede definierte SchnittsteUe. In dem dargesteU- 
ten Ausfuhrungsbeispiel speichert eine TabeUe "Produkti- 
dee" (PRODUCT IDEA TABLE) 310 alle verfugbaren Da- 
ten, die die Schnittstelle Productldea 210 verwenden, eine 
TabeUe "Produktanforderung" (PRODUCT REQUIRE- 
MENT TABLE) 320 speichert aUe zugegriffenen Daten, die 
die SchnittsteUe ProductRequirement 220 verwenden, eine 
TabeUe "Gestaltungsalternativen" (DESIGN ALTERNA- 
TIVE TABLE) 330 speichert aUe zugegriflfenen Daten, die 
die SchnittsteUe DesignAltemative 230 verwenden, eine Ta- 
beUe "GestaltungsdarsteUung" (DESIGN REPRESENTA- 
TION TABLE) 340 speichert aUe zugegriflfenen Daten, die 
die Schnittstelle DesignRepresentation 240 verwenden, eine 
Tabelle "Produktfunktion" (PRODUCT FUNCTION TA- 
BLE) 350 speichert aUe zugegriffenen Daten, die die 
SchnittsteUe ProductFunction 250 benutzen, eine Tabelle 
"Durchfuhrungsbeschrankung" (RFXJULATORY CON- 
STRAINT TABLE) 360 speichert alle zugegriffenen Daten, 
die die SchnittsteUe RegulatoryConstraint 260 verwenden, 
eine TabeUe "Gestaltungsabsicht" (DESIGN INTENT TA- 
BLE) 370 speichert aile zugegriffenen Daten, die die 
SchnittsteUe Designlntent 270 benutzen, eine Tabelle "Ge- 
staltungsbemerkung" (DESDNG NOTE TABLE) 380 spei- 
chert aUe zugegriffenen Daten, die die SchnittsteUe De- 
signNote 280 benutzen, eine TabeUe "(Jestaltungsproblem" 
(DESIGN ISSUE TABLE) 390 speichert aUe zugegriffenen 
Daten, die die SchnittsteUe Dcsignlssuc 290 verwenden. Zu- 
satzlich speichern die EntscheidungstabeUen "Produktan- 
forderungsentscheidung" (PRODUCT REQUIREMENT 
DECISION TABLE) 315, "Produktfunktionsentscheidung" 
(PRODUCT FUNCTION DECISION TABLE) 335, "Gc- 
staltungsdarsteUungsentscheiducg" (DESIGN REPRESEN- 
TATION DECISION TABLE) 345, "Gestaltungsalternati- 
venenlscheidung" (DESIGN ALTERNATIVE DECISION 
TABLE) 375 jeweils die zugegriffenen Daten, die die 
SchnittsteUen ProducfRequirementDecision 215, Product- 
FunctionDecision 235, DesignRepresentationDecision 245 
und DesignAllemaliveDecision 275 benutzen. Eine TabeUe 
"AnforderungserMlung" (REQUIREMENT FULFILL- 
MENT TABLE) 355 speichert die zugegriffenen Daten, die 
die SchnittsteUe RequirementFulfillment 255 benutzen. Die 
gestrichelten Linien, die die unterschiedhchen TabeUen mit- 
einander verbinden, steUen einen fremden Schlussel (fo- 
reign key) dar (d. h. eine gemeinsarae Spalte in jeder ver- 
bundenen relationalen Datenbank), der zur DarsteUung der 
Beziehungen in den TabeUen gespeicherten Daten verwen- 
det wird. 

[0052] Fig. 5 ist ein Anschauungsbeispiel einer relationa- 
len Datenbankdatei 410, die eine TabeUe "Produktidee" 310 
darsteUt. Wie dargesteUt, bildet jede Spalte "Beschreibung" 
(Description) 501 und "Name" 502 auf ein in der Schnitt- 
steUe Productldea 210 eingeschlossenes bzw. enthaltenes 
Attribut ab bzw. verweist auf dieses, und jede Reihe bildet 
auf ein unterschiedUches Objekt "Produktidee" 110 ab. 
[0053] Fig. 6 zeigt ein Anschauungsbeispiel einer relatio- 
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nalen Datenbankdatei 420, die eine TabeUe "Produktanfor- 
derung" 320 umsetzt. Wiederum bildet jede Spalte "Pro- 
duktideenname" (Product Idea Name) 601, "Beschreibung" 
(Description) 602, "Name" 603, "Kennung" (ID) 604, "Prio- 
s ritat" (Priority) 605 und "Gewichtung" (Weight) 606 jeweils 
auf ein in der SchnittsteUe ProductRequirement 220 einge- 
schlossenes bzw. enthaltenes Attribut ab bzw. verweist auf 
dieses, und jede Reihe bildet ein unterschiedUches Objekt 
"Produktanforderung" 120 ab. In diesem Beispiel istderPri- 
10 marschliissel (d. h. ein einziges Schlusselfeld (Identifier) fur 
die gesamte Datei) fur jedes Objekt "Produktanforderung" 
320 dessen Produktanforderungserkennung (in dieser Aus- 
fuhrungsform in Spalte 603 gespeichert). Das Attribut "Pro- 
duktideename" des Objekts "Produktidee", mit dem das Ob- 
ts jekt "Produktanforderung" 120 verbunden ist, wird als frem- 
der Schlussel bzw. KennbegrifT verwendet. Entsprechend 
wird eine Spalte "Fremder Schlussel" 601 bereitgesteUt, urn 
jeweibge Objekte "Produktanforderung" auf die zugeordne- 
ten Objekte "Produktidee" abzubilden. 
20 [0054] Fig. 7 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei 430, die eine Tabelle "Gestaltungsal- 
ternative" 330 umsetzL Die TabeUe umfaBt die Spalten 
("Produktideenname" (Product Idea Name) 701, "Beschrei- 
bung" (Description) 702, "Name" 703, "Status" 704, "Sta- 
25 tusgrund" (Status Reason) 705 und "Geschichte" (History) 
706. In diesem Beispiel wird das Attribut "Produktideen- 
name" des Objekts "Produktidee", dem das Objekt "Gestal- 
tungsaltemative" 130 zugeordnet ist, als fremder Schlussel 
verwendet. Entsprechend wird eine Spalte "Fremder Schliis- 
30 sel" 701 bereitgesteUt, um jeweilige Objekte "Gestaltungs- 
altemative" auf die zugeordneten Objekte "Produktidee" ab- 
zubilden. 

[0055] Fig. 8 ist ein Anschauungsbeispiel einer relationa- 
len Datenbankdatei 450, die eine TabeUe "Produktfunktion" 
35 350 umsetzt. Die TabeUe umfaBt die Spalten "Produktanfor- 
derungskennung" (Product Requirement ID) 801, "Gestal- 
tungsalternauvenname" (Design Alternative Name) 802 
"Beschreibung" (Description) 803, "Name" 804, "Relevanz" 
(is_relevant_for) 805. In diesem Beispiel wird das Attribut 
40 "Produktanfordcrungskcnnung" des Objekts "Produktanfor- 
derung", dem das Objekt "Produktfunktion" 150 zugeordnet 
ist, als ein fremder Schlussel und das Attribut "Gestaltungs- 
alternativenname" des Objekts "Gestaltungsaltemative", 
dem das Objekt "Produktfunktion" 150 zugeordnet ist, als' 
45 anderer fremder Schlussel verwendet. Entsprechend werden 
jeweiUge Spalten "Fremder Schlussel" 801 und 802 bereit- 
gesleUu um Objekte "Produklfunklion" 150 auf ihre jeweik- 
gen zugeordneten Objekte "Produktanforderung" 120 und 
"Gestaltungsaltemative" 130 abzubilden. 
50 [0056] Fig. 9 ist ein Anschauungsbeispiel einer relationa- 
len Datenbankdatei 455, die eine TabeUe "Anforderungser- 
fuUung" 355 umsetzt. Die TabeUe umfaBt die Spalten "Pro- 
duktfunktionsname" (Product Function Name) 901 und 
"Prozent" (Percent) 902. Wie dargesteUt, bUdet die Spalte 
55 902 auf das Attribut "Prozent" ab, das uberdie SchnittsteUe 
RequirementFulfillment" 255 eingeschlossen ist, und jede 
Reihe bildet auf ein anderes Objekt "Produktfunktion" ab. In 
diesem Beispiel wird das Attribut "Produktfunktionsname" 
des Objekts "Produktfunktion" 150 als fremder Schlussel 
60 verwendet, entsprechend wird eine Spalte "Fremder Schlus- 
sel" 901 bereitgesteUt, um ein Objekt "Anforderungserful- 
lung" auf sein zugeordnetes Objekt "Produktfunktion" 150 
abzubilden. 

[0057] Die anderen in Fig. 4 dargesteUten TabeUen sind in 
65 relationalen Datenbankdateien umgesetzt, die den in den 
Fig. 5 bis 9 dargesteUten ahnlich sind. 
[0058] Die Ablaufe, durch die bestimmte HM-Daten er- 
faBt werden, unterscheiden sich und sind abhangig davon, 
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welcher Typ von Daten erfaBt wird. Daten konnen erfaJBt 
werden, wenn ein Benutzer Daten iiber eine Dialogschnitt- 
stelle manuell eingibt (bspw. wenn ein Benutzer eine Pro- 
duktidee und zugeordnete vorgeschlagene Gestaltungsalter- 
nativen, Produktanforderungen und/oder Produktfunktionen 5 
unter Verwendung eines Produktideedialogs in der Benut- 
zerschnittstelle der Anwendung eingibt), oder konnen von 
einer Anwendung automatisch erzeugt werden (bspw. kon- 
nen Attribute wie Objektkennzeichner (Identifiers), Erzeu- 
gungszeit oder Datum der letzen Anderung von der Anwen- 10 
dung zu dem Zeitpunku an dem eine Information erfaBt oder 
geandert wird, automatisch erzeugt oder erfaBt werden). 
Fig. 10 zeigt beispielhaft einen Produktideedialog "Product 
Idea" 1000 einer grafischen Benutzerschnittstelle fur eine 
allgemeine Anwendung, die die Fahigkeit hat, auf ein erfin- 15 
dungsgemaBes IIM-Objektmodell lOe zuzugreifen und ein 
solches zu erzeugen. Wie dargestellt umfaBt der Produkt- 
ideedialog 1000 Benutzermoglichkeiten zum Eingeben ei- 
ner Beschreibung "Description" 1002 einer Produktidee und 
eines Namens "Name" 1004 fur die Produktidee. Der Pro- 20 
duktideedialog 1000 umfaBt auch Benutzermoglichkeiten 
(bspw. Knopfe'1006 und 1008) zum Eingeben vorgeschla- 
gener Produktanforderungen ("Requirement" 1006) undGe- 
staltungsalternativen ("Design Alternative" 1008) fur die 
Produktidee. Insbesondere wird ein in Fig. 11 dargestellter 25 
Produktanforderung-Dialog 1010 geoffnet bzw. eingeblen- 
det, wenn der Benutzer auf den Knopf "Requirement" 1006 
klickt. Wie in Fig. 1 1 dargestellt gestattet der Produktanfor- 
derungdialog "ProductRequirement" 1010 dem Benutzer, 
eine Beschreibung ("Description") 1012 der Produktanfor- 30 
derung, einen Namen 1014 fur die Produktanforderung und 
eine der Produktanforderung zugewiesene Prioritat ("Prio- 
rity Level") 1016 einzugeben. 

[0059] Auf die Benutzermoglichkeit zum Eingeben einer 
oder mehrerer vorgeschlagener Produktfunktionen zum teil- 35 
weisen oder vollstandigen Erfullen der Produktanforderung 
kann durch KUcken eines Knopfes "Function" 1018 zuge- 
griffen werden, wodurch ein in Fig. 12 dargestellter Dialog 
"Product Function" 1020 geoffnet bzw. eingeblendet wird. 
Wic in Fig. 12 dargestellt, kann der Benutzer die Fcldcr 40 
"Description" 1022 und "Name" 1024 der Funktion ausfiil- 
len und wahlweise an das Funktionsobjekt einen definierten 
Abschnitt (der dem System bekannt ist) anhangen, der der 
Anwendung gestattet, automatisch cin Objckt "Anfordc- 
rungserfiillung" 255 zu erzeugen, das angibt, wie gut die 
Produktfunktion die Produktanforderung erfullt. Unter 
"Function Definition" 1026 kann eine Funklionsdefiniuon 
eingegeben werden. 

[0060] Fig. 13 zeigt beispielhaft einen Gestaltungsalterna- 
tive-Dialog "Design Alternative" 1030, der von dem Dialog 
"Productldea" 1000 durch Klicken auf den Knopf "Geslal- 
tungsaltemative" (Design Alternative) 1008 erreicht werden 
kann. Wie dargestellt, gestattet der Dialog "Design Alterna- 
tive" 1030 einem Benutzer, eine Beschreibung ("Descrip- 
tion") 1032 einen Namen 1034, einen Status 1036 und einen 
Grund ("Reason") 1038 fur den Status 1036 einzugeben. 
Der Dialog "Design Alternative" 1030 kann auch einen 
Knopf "Produktfunktion" (Funktion) 1040 umfassen, der 
den Benutzer zu dem Produktfunktions-Dialog 1020 der 
Fig. 12 fiihrt, sowie einen Knopf "Produktfunktionsent- 
scheidung" (FunktionDecision) 1042, der einen (nicht dar- 
gestellten) Dialog offhet bzw. einblendet, der dem Benutzer 
gestattet, eine Entscheidung iiber jede den Gestaltungsent- 
wurf zugeordnete Produktfunktion einzugeben. 
[0061] Wie vorstehend ausfuhrlich beschrieben wurde, 
stellt die Erfindung einen neuen Weg des Erfassens und 
Speichems von sowie des Zugriffs auf Daten im Zusammen- 
hang mit der Verwaltung von Innovationsinformationen dar, 
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einschlieBlich dem inkrementalen Aufbau von Innovations- 
informationen einschlieBlich Produktideen, Gestallungsal- 
ternativen, Fragen und Antworten, die wahrend des Innova- 
tionsprozesses untersucht wurden, Gestaltungsentscheidun- 
gen usw. Die Innovationsinformationen werden in einer 
Form dargestellt, auf die in unterschiedlicher Weise zuge- 
griffen werden kann und die auf unterschiedliche Weise dar- 
stellbar ist, unter Verwendung von computerbasierten An- 
wendungen. 

[0062] Die Erfindung erfaBt den evulotionaren Aufbau 
von Informationen, die die urspriingliche Idee (Ausgangs- 
idee) und die Untersuchung eines Produkts iiber die Zeit be- 
treffen. Wahrend der Untersuchung eines Produkts werden 
viele Alternativen vorgeschlagen und erforscht. Entschei- 
dungen werden gefallt, die Moglichkeiten ausraumen bzw. 
ausschlieBen. Mit fortschreitender Gestaltung andem sich 
die gestellten Fragen und zugehorigen Antworten, da um- 
fassende Entscheidungen gefallt werden und detailliertere 
Fragestellungen auftreten.Teile der Produktdefinition bewe- 
gen sich von dem Status der Idee zu der fertigen Definition 
mit unterschiedlicher Geschwindigkeit. Das erfmdungsge- 
maBe Objektmodell zur verwaltung von Innovationsinfor- 
mationen unterstutzt dabei das Auffinden bzw. Nachvollzie- 
hen der funktionalen Wie-Ausgefuhrt-Aspekte des Pro- 
dukts. Dieses Auffinden stellt somit ein Zeitspektrum von 
der Untersuchung von Produktideen zu der vollstandigen 
und ftir die'Produktion freigegebenen Produktdefinition be- 
reiL Die Informationen eotwickeln sich dabei graduell und 
werden mit fortschreitendem GestaltungsprozeB detaiUier- 
ter. Die Moglichkeit fur Innovation ist so lang gegeben, so 
lange Fragen offen bleiben, die kreative Antworten benoti- 
gen. Die Auswirkung von Innovation bewegt sich von der 
umfassenden Ebene auf detailliertere Ebenen, wenn Ent- 
scheidungen gefallt werden und Details beriicksichtigt wer- 
den. 

[0063] Die Erfindung vereinfacht den Zugriff auf Infor- 
mationen durch jede Anwendung iiber die definierten Ob- 
jektmodellschnittstellen, unabhangig davon, welche An- 
wendung die Objekte erzeugt hat. Somit "gehoren" die Da- 
ten kcincr Anwendung und auch kcincm Wcrkzcug, das die 
Daten erzeugt hat. 

[0064] Die Erfindung vereinfacht auch anspruchsvolle Su- 
chen in den Objektmodellen, urn interessierende Informatio- 
nen aus der Gcsamthcit der gcspcichcrtcn Informationen 
45 herausfinden. Die Erfindung ist aus vielen Griinden vortcil- 
haft, einschlieBlich der Tatsache, daB viele Benutzer mit un- 
terschiedlichen Aufgaben auf eine Art und Weise, die ihrer 
jeweiligen Aufgabe bzw. Bedeutung gerecht wird, auf die 
Informationen zuzugreifen und Informationen herauszuzie- 
50 hen. 

[0065] Wie nach der Lekliire der vorslehenden ausfuhrli- 
che Beschreibung offensichdich wird, verfugt die Erfindung 
iiber einige Vorteile gegenuber.dem Stand der Technik. Das 
erfmdungsgemaBe ETM-Objektmodell erhdht die Effizienz 
55 beim Nachvollzieben und Verstehen, wie und warura eine 
Produktgestaltung eine derzeitige Konfiguration aufweist. 
Das erfmdungsgemaBe HM-Objektmodell gestattet das Er- 
fassen und Nachvollziehen von funktionalen Wie-Gestaltet- 
Aspekten des Produkts anstelle der Wie-Ausgefuhrt-Konfi- 
60 guration des endgultigen Produkts und stellt dadurch ein 
Zeitspektrum von der anfanglichen Untersuchung von Pro- 
duktideen bis zu der vollstandigen und zur Produktion frei- 
gegebenen Produktdefinition bereit. Die Informationen ent- 
wickeln sich graduell und werden mit fortschreitendem Ge- 
65 staltungsprozeB immer detaillierter. 
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1. Objektmodell zum Erfassen von Informational, die 
produktinno vationsbezogene Daten betreffen, rait einer 
Produktideeschnittstelle zum Erfassen einer Idee fur 
ein Produkt in einem Produktideeobjekt und einer Ge- 
staltungsalternativenschnittstelle zum Erfassen einer 
Vielzahl von Gestaltungsalternativen fur das Produkt in 
einer Vielzahl von jeweiligen Gestaltungsalternative- 
Objekten. 

2. Objektmodell nach Anspruch 1, mit einer Produk- 
tanforderungsschnittstelle zum Erfassen einer Anfor- 
derung fur die Produktidee in einem Produktanforde- 
rungsobjekt. 

3. Objektmodell nach Anspruch 2, mit einer Produkt- 
funktionsschnittstelle zum Erfassen einer Funktion 
zum Erfullen der Produktanforderung in einem Pro- 
duktfunktionsobjekt. 

4. Objektmodell nach Anspruch 3, mit einer Produkt- 
erfiillungsschnittstelle, die erfafit, wie gut die Produkt- 
funktion die Produktanforderung erfullL 

5. Objektmodell nach Anspruch 1, mit einer Gestal- 
tungsdarstellungsschnittstelle zum Erfassen einer Dar- 
stellung der Gestaltungsalternative in einem Gestal- 
tungsdarstellungsobjekt. 

6. Objektmodell nach Anspruch 1, mit einer Hntschei- 
dungsschnittstelle zum Erfassen einer Entscheidung in 
einem Produktanforderungsobjekt, wobei diese Ent- 
scheidung entweder die Produktidee oder die Gestal- 
tungsalternative betrifft. 

7. Objektmodell nach Anspruch 1, bei dem Produkti- 
deeobjekt und jedes Gestaltungsalternative-Objekt in 
einer werkzeugneutralen bestandigen Form gespeichert 
werden. 

8. Objektmodell nach Anspruch 2, bei dem Produkti- 
deeobjekt, jedes Gestaltungsalternative-Objekt und je- 
des Produktanforderungsobjekt in einer werkzeugneu- 
tralen bestandigen Form gespeichert werden. 

9. Objektmodell nach Anspruch 5, bei dem Produkti- 
deeobjekt, jcdcs Gcstaltungsaltcmativc-Objckt und je- 
des Gestaltungsdarstellungsobjekt in einer werkzeug- 
neutralen bestandigen Form gespeichert werden. 

10. Verfahren zum Erfassen von Informationen, die 
produktinnovationsbczogene Daten betreffen, mit den 
folgenden Schritten: 

Erfassen einer Idee fur ein Produkt in einem Produkti- 
deeobjekt, und 

Erfassen einer Vielzahl von Gestaltungsalternativen fur 
das Produkt in einer Vielzahl von entsprechenden Ge- 
staltungsalternative-Objekten. 

11. Verfahren nach Anspruch 10, mil deiti Schritt des 
Erfassens einer Anforderung fur die Produktidee in ei- 
nem Produktanforderungsobjekt. 

12. Verfahren nach Anspruch 11, mit dem Schritt des 
Erfassens eine Funktion zum Erfullen der Produktan- 
forderung in einem ProduktfunktionsobjekL 

13. Verfahren nach Anspruch 10, mit dem Schritt des 
Erfassens einer Darstellung der Gestaltungsalternative 
in einem Gestaltungsdarstellungsobjekt. 

14. Verfahren nach Anspruch 10, mit dem Schritt des 
Erfassens einer Entscheidung in einem Entscheidungs- 
objekt, wobei die Entscheidung entweder die Produkti- 
dee oder die Gestaltungsalternative betrifft. 

15. Verfahren nach Anspruch 1, mit dem Schritt des 
Speichems des Produktideeobjekts und jedes Gestal- 
tungsalternative-Objekts in einer werkzeugneutralen 
bestandigen Form. 

16. Verfahren nach Anspruch 10, mit dem Schritt des 
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Speichems des Produktideeobjekts, jedes Gestaltungs- 
alternative-Objekts und des Produktanforderungsob- 
jekts in einer werkzeugneutralen bestandigen Form. 

17. Verfahren nach Anspruch 13, nut dem Schritt des 
Speichems des Produktideeobjekts, jedes Gestaltungs- 
altemative-Objekts und jedes Gestaltungsdarstellungs- 
objekts in einer werkzeugneutralen bestandigen Form. 

18. Computerprogramm mit Programmanweisungen, 
die ein Verfahren zum Erfassen von Informationen, die 
produktinnovationsbezogene Daten betreffen, umset- 
zen, wobei das Verfahren die folgenden Schritte um- 
faBt: 

Erfassen einer Idee fur ein Produkt in einem Produkti- 
deeobjekt, und 

Erfassen einer Vielzahl von Gestaltungsalternativen fur 
das Produkt in einer Vielzahl von jeweiligen Gestal- 
tungsalternative-Objekten. 

19. Computerprogramm nach Anspruch 18, bei dem 
das Verfahren den Schritt des Speichems des Produkti- 
deeobjekts und jedes Gestaltungsaltemative-Objekts in 
einer werkzeugneutralen bestandigen Form umfaBt. 

20. Computerprogramm nach Anspruch 18, wobei das 
Verfahren die folgenden Schritte umfaBt: 

Erfassen einer Anforderung fur die Produktidee in ei- 
nem Produktanforderungsobjekt, 
Erfassen einer Darstellung der Gestaltungsalternative 
in einem Gestaltungsdarstellungsobjekt, und 
Speichern des Produktideeobjekts, jedes Gestaltungs- 
altemative-Objekts, des Produktanforderungsobjekts 
und jedes Gestaltungsdarstellungsobjekts in einer sepa- 
raten relationalen Datenbank, wobei VerknUpfungen 
zwischen den einzelnen Objekten unter Verwendung 
fremder Schliissel erfaBt werden. 
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